home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ietf / 92mar / mplxmib-minutes-92mar.txt < prev    next >
Text File  |  1993-02-17  |  9KB  |  213 lines
  1. This is only a rough draft - Megan 04/08/92
  2.  
  3. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  4.         Multiplexing SNMP Agents BOF
  5.  
  6. These are the minutes of the Multiplexing SNMP agent BOF held at the
  7. Spring 1992 IETF meeting in San Diego, California.
  8.  
  9. The meeting was chaired by Karl Auerbach and minutes were taken by Ed
  10. Alcoff.
  11.  
  12. The meeting began with a quick pair of slides restating the purpose
  13. of the BOF and a straw man proposal:
  14.  
  15. ======================================================================
  16.             SLIDE 1
  17.  
  18. The purpose of this BOF is to determine:
  19.  
  20.     a) Whether SMUX or DPI are adequate.
  21.  
  22.     b) Whether the proxy capabilities in secure SNMP are adequate.
  23.  
  24.     c) If neither a) nor b) are adequate, why not?
  25.        In other words, what sorts of functions do users
  26.        think they need from a multiplexing SNMP agent?
  27.  
  28.     d) What sort of solutions might exist
  29.  
  30.         i) If the solutions are limited to the Unix operating
  31.            system?
  32.  
  33.         ii) If the solutions are generalized to cover Unix
  34.             and other environments?
  35.  
  36. Goal:
  37.  
  38. The goal of this BOF is to make an inquiry regarding the scope of the
  39. issue and the range of potential solutions.
  40. ======================================================================
  41.  
  42.  
  43. ======================================================================
  44.             SLIDE 2
  45.  
  46. Straw man:
  47.  
  48. To begin the discussion, here are some criteria I think might be
  49. appropriate for a multiplexing agent:
  50.  
  51. 1. New MIB sub-trees may be attached *and* detached at any time.
  52.  
  53. 2. Sub-trees may not be nested.  In other words, an attached sub-tree
  54.    may not have dynamically attached lower level sub-trees.
  55.  
  56. 3. The master agent must not be required to have a priori knowledge
  57.    of what is in the subtrees.  (In other words, that agent ought to
  58.    be able to accept any arbitrary subtree.)
  59.  
  60. 4. Get-next must work across subtree boundaries.
  61.  
  62. 6. Get-requests and Get-next requests must be allowed to have
  63.    varBind entries which refer to elements in multiple subtrees.
  64.    In other words, a single get/getnext ought to be able to fetch
  65.    stuff in multiple sub-trees.
  66.  
  67. 7. A set-request ought to be able to contain varBind entries which 
  68.    refer to elements in multiple subtrees.  And the "as if
  69.    simultaneous" requirement must be preserved across subtrees.
  70.  
  71.    This one we might want to debate.
  72.  
  73. 8. The multiplexing scheme must be robust despite sub-agent failures.
  74.    (I.e. a request ought not hang forever if a sub-agent is non-responsive.)
  75.  
  76. 9. The multiplexing scheme need only support sub-agents on the same
  77.    machine as the primary agent.
  78.  
  79. 10. Multi-agent/multi-protocol capability: The multiplexing protocol
  80.    ought to be designed so that a given subordinate agent could
  81.    support multiple superior agents.  In addition, the protocol ought
  82.    to be rich enough that those superior agents aren't just SNMP
  83.    agents.
  84. ======================================================================
  85.  
  86.  
  87. DISCUSSION:
  88.  
  89. The BOF started with discussion of the "10" points listed on slide #2.
  90.  
  91. 1.  No one strongly disputed the need for dynamic growth or
  92. contraction of the MIB tree.
  93.  
  94. 2. It was pointed out that one may want to have different instances
  95. of a variable or group "owned" by a different sub-agents.  For
  96. example, each row of a table may be provided by a separate sub-agent
  97. rather than having the entire table provided by a single sub-agent.
  98. This appears to be a useful point of view.  It is, however,
  99. significantly at odds with previous thinking in which all instances
  100. of any given variable would be "owned" by a single sub-agent.
  101.  
  102. 3.  A model was proposed in which there would be multiple,
  103. independent sub-agents rather than a single master multiplexing SNMP
  104. agent.  In this new model, each agent would emit a start-up trap
  105. announcing its service address.  A management station would then
  106. address independent SNMP queries to the appropriate agent.
  107.  
  108. 4.  Problem with both SMUX & DPI was noted: Because of the
  109. uncoordinated activities of the various sub-agents, the correlation
  110. of sysUpTime with sub-agent derived information may be weak and may
  111. vary unpredictably.  It may be difficult, if not impossible, to
  112. provide a useful correlation between time stamps (such as sysUpTime)
  113. and readings of management variables.
  114.  
  115. 5.  A concern was raised whether effective network management
  116. requires that a management station be able to issue an SNMP
  117. varBindList which has items spanning MIB subtrees owned by separate
  118. sub-agents.
  119.  
  120. One participant asked whether this was a non-issue.  In particular,
  121. does it really matter whether a query is split among agents (or
  122. sub-agents) by the SNMP manager station itself or by a master agent?
  123.  
  124. In further discussion, it was suggested that since the agent is
  125. "closer" to the sub-agents it is in a better position to know how to
  126. best partition queries.  Partitioning by the agent also has the
  127. advantage that get-next semantics can be preserved even where the
  128. next lexiographic item lies across a sub-agent boundary.
  129.  
  130. Another participant commented that whenever a MIB is partitioned
  131. among sub-agents, it is necessary to replicate at least the System
  132. group in each partition.  Thus it would be possible to retrieve
  133. timestamps which are correlated with the data values.
  134.  
  135. A question was raised whether the sysUpTime value of the various
  136. partitions need to be synchronized.  A well known pragmatist answered
  137. that on most hosts, it is quite easy to keep the various instances of
  138. sysUpTime fairly well synchronized.  This left unanswered the
  139. question whether such synchronization is needed when the sub-agents
  140. reside on separate processors.
  141.  
  142. 6.  Looking to practice, do people actually issue queries which deal
  143. with logically separate information bases (each of which presumably
  144. would be handled by a separate sub-agent)?
  145.  
  146. On one hand would one ever realistically want to ask about routing
  147. tables and sendmail in the same SNMP query?  Probably not.
  148.  
  149. On the other hand, one could conceive of a query which tried to
  150. correlate network traffic load with changes in routing topology.  And
  151. it is not unreasonable to believe that load measurement and routing
  152. topology would be maintained in separate sub-agents.
  153.  
  154. It was pointed out that many SNMP managers do not recognize the
  155. notion that a single managed device may contain multiple SNMP
  156. entities.  Consequently, many managers today present such devices on
  157. the user interface as if they were multiple, separate devices.
  158.  
  159. 7.  It was asked to what extent existing multiplexed SNMP agents
  160. enforce the "as if simultaneous" atomic requirements of SNMP
  161. Set-Requests.
  162.  
  163. It appears that a significant number of existing multiplexed agents
  164. do not make this guarantee.  This has not, to date, appeared to have
  165. caused any operational difficulties.  However, this may be the result
  166. of simplistic user interfaces which limit set-requests to one value,
  167. proprietary MIBs which are designed so as to avoid the need for
  168. atomic "sets", or to adolescent tools which do not yet push
  169. Set-Requests very hard.
  170.  
  171. 8.  There was discussion regarding the implementation burden on
  172. sub-agent writers.  At a minimum, there was a desire to avoid
  173. encoding and decoding ASN.1/BER.  Alternatives suggested were XDR or
  174. simplified BER.  If the agent-sub-agent interface did not cross
  175. machine boundaries then one could even use internal, host specific
  176. data formats.
  177.  
  178. Some people wanted to go further and isolate sub-agents from the
  179. issues of object naming, object instancing, and lexiographic
  180. ordering.  It was hoped that the agent-to-sub-agent interface could
  181. be hidden behind a clean programming API.  There was no consensus,
  182. however, whether this is feasible unless done in the context of a
  183. specific operating system.
  184.  
  185. 9.  DEC, HP, IBM, and Peer Networks quickly described their own
  186. methods of dealing with some or all of the issues.
  187.  
  188. 10.  Marshall Rose described a means using the Secure SNMP protocols
  189. and MIB to partition the management variable space among multiple
  190. sub-agents.  Each "party" would be mapped to a separate sub-agent.
  191.  
  192. It was pointed out that this is really a variation of the "completely
  193. disjoint agent" method #3, above.
  194.  
  195. SUMMARY:
  196.  
  197. There is strong interest in multiplexing SNMP agents.  A number of
  198. multiplexing agents or extensible agents have been constructed.  And
  199. various attendees have built multi-protocol agents and managers.
  200.  
  201. The requirements are not yet well understood.  In particular, a
  202. significant number of attendees were of the opinion that it is not
  203. necessary to preserve full SNMP query semantics across sub-agent
  204. boundaries or that it is acceptable for an agent to fail to honor the
  205. "as it simultaneous" and atomic properties of SET requests.
  206.  
  207. Using the proxy facility of the forthcoming secure SNMP would easily
  208. and directly provide a means to divide MIBs among separate
  209. sub-agents.  But it would require that a management station be aware
  210. of the MIB partions.
  211.  
  212.  
  213.